home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1475.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.8 KB  |  59 lines
  1. Thus wrote: Rob Raisch
  2. >I strongly disagree.  The security issue is inherent in the network, not
  3. >in URLs. We should not attempt to scale some moral high ground simply to
  4. >stop up some possible security holes, which are not ours to stop up in the
  5. >first place. 
  6. >
  7. >The answer to insecure network services is to make them more secure, not
  8. >to limit the deployment and usefulness of URLs. 
  9. >
  10. >If a dedicated cracker wishes to break the system, I would suggest that
  11. >writing an HTML document, and using that as a lock pick on doors which
  12. >have no locks to begin with, would be a marvelous exercise in stupidity.
  13.  
  14. I believe we should have an attitude similar to that of MIME regarding
  15. security:
  16.  
  17. - Security is more important than interoperability
  18. - No additions should be made without a careful review of possible
  19.   security issues
  20. - User agents should present the user with sufficient information for
  21.   the user to avoid possible traps, and should do so in a way that
  22.   even a relatively inexperienced user can understand
  23.  
  24. Allowing an attacker to cause a victim to telnet to an arbitrary port
  25. on an arbitrary machine and send arbitrary data certainly has some
  26. potential risks.
  27.  
  28. Scenario:  Someone installs a document with a hyperlink that, when
  29. activated, causes bad mail (say, a death threat) to be mailed to the
  30. President of your organization/university/whatever.  You click on it.
  31. Depending on the implementation of the client, you may or may not see
  32. anything out of the ordinary, and you may or may not understand what
  33. it means.  If the attacker is clever, it's labeled something like
  34. "Click here to see some sample SMTP output."
  35.  
  36. Three days later, you are brought up on charges of mailing a death
  37. threat.  An investigation of transfer logs, RFC 931 authentication
  38. protocols, or whatever reveal that the message did come from your
  39. account/machine (which is correct; it *did*.)  You have no idea what
  40. happened.  Even if you did suspect a bad hyperlink, the offending HTML
  41. document has been changed (and may have even been rigged by the server
  42. to only look that way for you, and only once.)
  43.  
  44. That's just an offhand scenario.  It might also be possible to forge
  45. postings (including control postings that do damage, like sendsys or
  46. rmgroup or cancel) or muck with other widely used protocols.
  47.  
  48. Being able to do that kind of arbitrary URL referencing would have
  49. some advantages, and would lessen the need for gateways; this is good.
  50. My own inclination is that a client would have to take significant
  51. steps to reduce the risk of problems, and that the advantage of this
  52. kind of URL would be outweighed by the added inconvenience of users
  53. being warned of arbitrary transactions for approval (not to mention
  54. the trouble for client writers.)  That's just an inclination, though.
  55. I'd be interested in the results of a security review; maybe it's not
  56. as much a problem as I'm guessing.
  57.  
  58. - Marc
  59.